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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The present document is part of a TS-family covering the 3rd Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication management, as identified below: 

TS 32.421: "Subscriber and equipment trace: Trace concepts and requirements"; 

TS 32.422: "Subscriber and equipment trace: Trace control and configuration management"; 

TS 32.423: "Subscriber and equipment trace: Trace data definition and management"; 

Additionally, there is a GSM only Subscriber and Equipment Trace specification: 3GPP TS 52.008 [5]. 

Subscriber and Equipment Trace provide very detailed information at call level on one or more specific mobile(s). This 
data is an additional source of information to Performance Measurements and allows going further in monitoring and 
optimisation operations. 

Contrary to Performance Measurements, which are a permanent source of information. Trace is activated on user 
demand for a limited period of time for specific analysis purposes. 

Trace plays a major role in activities such as determination of the root cause of a malfunctioning mobile, advanced 
troubleshooting, optimisation of resource usage and quality, RF coverage control and capacity improvement, dropped 
call analysis. Core Network and UTRAN end-to-end UMTS procedure validation. 

The capability to log data on any interface at call level for a specific user (e.g. IMSI) or mobile type (e.g. IMEI or 
IMEISV), or service initiated from a UE allows getting information which cannot be deduced from Performance 
Measurements such as perception of end-user QoS during his call (e.g. requested QoS vs. provided QoS), correlation 
between protocol messages and RF measurements, or interoperability with specific mobile vendors. 

Moreover, Performance Measurements provide values aggregated on an observation period. Subscriber and Equipment 
Trace give instantaneous values for a specific event (e.g., call, location update, etc.). 

If Performance Measurements are mandatory for daily operations, future network planning and primary trouble 
shooting. Subscriber and Equipment Trace is the easy way to go deeper into investigation and UMTS network 
optimisation. 

In order to produce this data. Subscriber and Equipment Trace are carried out in the NEs, which comprise the network. 
The data can then be transferred to an external system (e.g. an Operations System (OS) in TMN terminology, for further 
evaluation). 
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Scope 



The present document describes the mechanisms used for the control and configuration of the Trace functionahty at the 
EMs, NEs and UEs. It covers the triggering events for starting/stopping of subscriber/UE activity traced over 3GPP 
standardized signalling interfaces, the types of trace mechanisms, configuration of a trace, level of detail available in the 
trace data, the generation of Trace results in the Network Elements (NEs) and User Equipment (UE) and the transfer of 
these results to one or more EM(s) and/or Network Manager(s) (NM(s)). 

The mechanisms for Trace activation/deactivation are detailed in clause 4; clause 5 details the various Trace control and 
configuration parameters and the triggering events that can be set in a network. Trace concepts and requirements are 
covered in 3GPP TS 32.421 [2] while Trace data definition and management is covered in 3GPP TS 32.423 [3]. 



References 



The following documents contain provisions, which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

NOTE: Overall management principles are defined in 3GPP TS 32.101 [1]. 

[I] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.421: "Telecommunication management; Subscriber and equipment trace: Trace 

concepts and requirements". 

[3] 3GPP TS 32.423: "Telecommunication management; Subscriber and equipment trace: Trace data 
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[5] 3GPP TS 52.008: "Telecommunication management; GSM subscriber and equipment trace". 

[6] 3GPP TS 23.060: "General Packet Radio Service (GPRS) Service description; Stage 2". 

[7] 3GPP TS 23.205: "Bearer-independent circuit-switched core network; Stage 2". 

[8] 3GPP TS 23.108: "Mobile radio interface layer 3 specification core network protocols; Stage 2 

(structured procedures)". 

[9] 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional 

description". 

[10] 3GPP TS 29.232: "Media Gateway Controller (MGC) - Media Gateway (MGW); interface; 

Stage 3". 

[II] 3GPP TS 29.002: "Mobile Apphcation Part (MAP) specification". 

[12] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) 

across the Gn and Gp interface". 

[13] 3GPP TS 25.413 : "UTRAN lu interface RANAP signalling". 

[14] 3GPP TS 23.218: "IP Multimedia (IM) session handhng; IM call model; Stage 2". 
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[15] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

[16] 3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx and Dx Interfaces; SignalUng flows and 

message contents". 

[17] 3GPP TS 29.328: "IP Multimedia Subsystem (IMS) Sh interface; Signalling flows and message 

contents". 

[18] Enabler Release Definition for OMA Device Management Specifications, version 1.2, The Open 

Mobile Alliance'''^ ( URL:http://www. openmobilealliance.org/ ). 

[19] 3GPP TS 32.240: "Telecommunication management; Charging management; Charging 

architecture and principles". 

[20] 3GPP TS 32.260: "Telecommunication management; Charging management; IP Multimedia 

Subsystem (IMS) chai-ging". 



Abbreviations 



For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [4], 3GPP TS 32.101 [1] and the 
following apply: 

AS Application Server 

BGCF Breakout Gateway Control Function 

CSCF Call Session Control Function 

I-CSCF Interrogating-CSCF 

IM CN SS IP Multimedia Core Network Subsystem 

MRFC Multimedia Resource Function Controller 

P-CSCF Proxy - CSCF 

S-CSCF Serving-CSCF 

4 Trace activation and deactivation 

4.1 Trace session activation / deactivation 
4.1.1 Management activation 
4.1.1.1 General 

In Management activation, the Trace Control and Configuration parameters are sent directly to the concerned NE (by its 
EM). This NE shall not propagate the received data to any other NE's - whether or not it is involved in the actual 
recording of the call. 

Once the parameters have been provided, the NE looks for the IMSI or IMEI (IMEIS V) passing through it. If it does not 
have them, these shall be provided to the NE (that performs the trace recording) as part of traffic signalling by the CN. 

The following figure represents the management based trace functionality within a PLMN. The figure represents a 
typical PLMN network. A dotted arrow with "Trace Parameter Configuration" represents the availability of the 
management based trace functionality at the EM for that domain. 

NOTE: There is no propagation of trace parameters in management based trace activation. 
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Figure 4.1 .1 .1 .1 : Overview of management activation 
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4.1 .1 .2 UTRAN activation mechanisms 

When an RNC receives Trace Session activation from the EM it shall start a Trace Session. The trace control and 
configuration parameters of the Trace Session are received in Trace Session activation from the EM. The RNC shall not 
forward these trace control and configuration parameters to other nodes. The received trace control and configuration 
parameters shall be saved and used to determine when and how to start a Trace Recording Session. (Starting a Trace 
Recording Session is described in subclause 4.2.2.1). A Trace Session may be requested for a limited geographical area. 

Since a RNC has visibility of an IMSI, it can start an IMSI Trace all by itself when a Trace session is requested for an 
IMSI or a list of IMSI's. However, a RNC does not have visibility of the IMEI(SV). Hence, when a Trace session is 
requested for an IMEI(SV) or a Hst of IMEI(SV), the RNC shall send the requested IMEI(SV) / Hst of IMEI(SV)s in an 
'Uplink Information Exchange Request' message to the interacting MSC Server(s) and SGSN(s). The MSC Servers and 
SGSNs shall store the requested IMEI(SV)s per RNC. For each subscriber/UE activity the MSC Servers and SGSNs 
shall request IMEI(SV), if it is not already provided. For each subscriber/UE activity the MSC server/SGSN shall check 
whether a trace request is active in an RNC for the IMEI(SV). If a match is found, the MSC Server/SGSN shall inform 
the RNC about the IMEI(S"V) in CN Invoke Trace, so that the RNC can trace the control signalling according to the 
trace control and configuration parameters that are received from its EM. 

If an Inter-MSC SRNS Relocation or an Inter-SGSN SRNS relocation occurs, the anchor MSC Server or source SGSN 
shall transfer the IMSI and IMEI(SV) for the subscriber/UE activity to the non anchor MSC Server or target SGSN. The 
non anchor MSC Server/target SGSN shall check whether it has received a trace request from the target RNC for the 
transferred IMEI(S V). If a match is found on the IMEI(SV) in the non anchor MSC Server/target SGSN, the MSC 
Server/SGSN shall inform the RNC about the IMEI(SV) in the CN Invoke Trace. The IMSI shall be transferred from 
the non anchor MSC Server/target SGSN to the target RNC in Relocation Request. The RNC can then trace the 
subscriber/UE activity according to the trace control and configuration parameters that are received from its EM. 

4.1 .1 .3 PS Domain activation mechanisms 

When a SGSN, GGSN or BM-SC receives Trace Session activation from the EM it shall start a Trace Session. The 
trace control and configuration parameters of the Trace Session are received in the Trace Session activation from the 
EM. The SGSN/GGSN/BM-SC shall not forward these trace control and configuration parameters to other nodes. The 
received trace control and configuration parameters shall be saved and used to determine when and how to start a Trace 
Recording Session. (Starting a Trace Recording Session is described in subclause 4.2.2.2) 

4.1 .1 .4 CS Domain activation mechanisms 

When a MSC Server receives Trace Session activation from the EM it shall start a Trace Session. The trace control and 
configuration parameters of the Trace Session are received in the Trace Session activation from the EM. The MSC 
Server shall not forward these trace control and configuration parameters to other nodes. The received trace control and 
configuration parameters shall be saved and used to determine when and how to start a Trace Recording Session. 
(Starting a Trace Recording Session is described in subclause 4.2.2.3) 
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4.1.1.5 



IP Multimedia Subsystem activation mechanisms 



When a S-CSCF/P-CSCF receives Trace Session activation from EM, the S-CSCF/P-CSCF shall start a Trace Session. 
The Trace control and configuration parameters of the Trace Session, received from EM in the Trace Session activation, 
shall be saved. The Trace control and configuration parameters define when the S-CSCF and P-CSCF shall start and 
stop a Trace Recording Session. For detailed information on starting and stopping Trace Recording Session in IMS see 
sub clauses 4.2.2.4 and 4.2.4.4. 

The following figure illustrates the Trace Session activation in S-CSCF and in P-CSCF in case of Management based 
activation. 
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Trace Session Activaion 



Trace Session activated 
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Figure 4.1.1.5.1: Trace Session activation in IIVIS 



4.1.2 Signalling activation 



4.1.2.1 



General 



In Signalling activation, the Trace Activation shall be carried out from the Core Network EM only [EM (PS), EM (CS), 
and EM (HSS), EM (UE) are generally considered to be in the Core Network. A Core Network EM can be any of these 
or their combinations]. 

In case of home subscriber trace (i.e. in the HPLMN) the Trace Session activation shall go to the HSS / MSC Server / 
SGSN. Instances where the home subscriber is roaming in a VPLMN, the HSS may initiate a trace in that VPLMN. The 
VPLMN may reject such requests. 

In case of foreign subscriber trace (i.e. the HPLMN operator wishes to trace foreign subscribers roaming in his PLMN) 
the Trace Session activation shall go the MSC Server/VLR or SGSN. Depending on the Trace Control and 
Configuration parameters received, the Core Network shall propagate the activation to selected NE's in the entire 
network - UTRAN and CN. 
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4.1.2.2 



Intra PLMN signalling activation 



The following figure represents the signalling based trace functionality within a PLMN. The figure represents a typical 
PLMN network. A dotted arrow with "Trace Parameter Configuration" represents the availability of the trace 
functionality at the EM for that domain. E.g. you cannot invoke a Signalling Trace at the EM (UTRAN) because there is 
no such arrow shown in the figure. You can however do it from the EM (CS Domain). Similarly "Trace Parameter 
Propagation" is allowed only for the interfaces indicated in the figure. E.g. there is no parameter propagation over lu-B. 

NOTE: For tracing on the basis of IMEI(S V), the signalling based activation can be only initiated from the 
MSC/VLR or SGSN. 
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Figure 4.1 .2.2.1 : Overview of intra-PLIUIN Signalling Activation 
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4.1 .2.3 Inter PLMN Signalling Activation 

The following figure represents the signalling based trace functionality between PLMNs. This is particularly useful 
when a roaming subscriber needs to be traced in a network. The figure represents a typical PLMN network and its 
connections with another PLMN's HSS. A dotted arrow with "Trace Parameter Configuration" represents the 
availability of the trace functionality at the EM for that domain. E.g. you cannot invoke a Signalling Trace at the EM 
(UTRAN) because there is no such arrow shown in the figure. You can however do it from the EM (CS Domain). 
Similarly "Trace Parameter Propagation" is allowed only for the interfaces indicated in the figure. E.g. there is no 
parameter propagation over lu-B. 

NOTE: There is no intention to allow tracing of a home subscriber roaming in a foreign network i.e. the trace 
function is limited to a single PLMN. 
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Figure 4.1.2.3.1 : Overview of Inter-PLIUIN Signalling Activation 
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4.1 .2.4 UTRAN activation mechanisms 

See subclause 4.2.3.1. 

4.1.2.5 PS Domain activation mechanisms 

The following figure shows the Trace Session activation in the PS domain. The figure is an example of tracing PDP 
context. 
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Figure 4.1.2.5.1 : Trace session activation in PS domain for PDP Context 

When a UE registers with the network by sending an ATTACH_REQUEST message to the SGSN, it updates the 
location information in the HSS by sending the UPDATE_GPRS_LOCATION message to the HSS. The HSS checks if 
the UE is being traced. If it is being traced, the HSS shall propagate the trace control and configuration parameters to 
the SGSN by sending a MAP-ACTIVATE_TRACE_MODE - see 3GPP TS 29.002 [11] message to the SGSN. When 
an inter-SGSN routing area update occurs, HSS shall send the MAP-ACTIVATE_TRACE_MODE message to the new 
SGSN. 

When SGSN receives the MAP-ACTIVATE_TRACE_MODE message it shall store the trace control and configuration 
parameters and shall start a Trace Session. 

When any of the triggering events defined in the trace control and configuration parameters occur, (e.g. PS session is 
started (i.e. a ACTIVATE PDP CONTEXT REQUEST message is received from the UE)) the SGSN shall propagate 
the trace control and configuration parameters to the GGSN (by sending a GTP- 
CREATE_PDP_CONTEXT_REQUEST message) and to the radio network (by sending a RANAP- 
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CN_INVOKE_TRACE message), if it is defined in the trace control and configuration parameters (NE types to trace). 
The Trace Session activation to UTRAN is described in clauses 4.1.2.4. 

When HSS sends the MAP-ACTIVATE_TRACE_MODE message to SGSN it shall include the following parameters 
to the message: 

• IMSI (M). 

• Trace reference (M). 

• Triggering events for SGSN (M) and GGSN (M). 

• Trace Depth for SGSN (M), GGSN (M) and RNC (M). 

• List of NE types to trace (M). 

• List of interfaces for SGSN (O), GGSN (O) and/or RNC (O). 

When the SGSN sends the GTP-CREATE_PDP_CONTEXT_REQUEST message to GGSN it shall include the 
following parameters to the message: 

• IMSI or IMEI (SV) (M). 

• Trace reference (M). 

• Trace Recording Session Reference (M). 

• Triggering events for GGSN (M). 

• Trace Depth for GGS N (M) . 

• List of interfaces for GGSN (O). 

The following figure is an example of tracing for MBMS Context. 
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Figure 4.1.2.5.2: Trace session activation in PS domain for IVIBIVISContext 

When HSS receives a Trace Session activation from its EMS, it shall store the received trace control and configuration 
parameters. At this point a Trace Session shall be started in the HSS. 

When a UE registers with the network by sending an ATTACH_REQUEST message to the SGSN, it updates the 
location information in the HSS by sending the UPDATE_GPRS_LOCATION message to the HSS. The HSS checks if 
the UE is being traced. If it is being traced, the HSS shall propagate the trace control and configuration parameters to 
the SGSN by sending a MAP-ACTIVATE_TRACE_MODE message to the SGSN. When an inter-SGSN routing area 
update occurs, HSS shall send the MAP-ACTIVATE_TRACE_MODE message to the new SGSN. 

When SGSN receives the MAP-ACTIVATE_TRACE_MODE message it shall store the trace control and configuration 
parameters and shall start a Trace Session. 

When any of the triggering events defined in the trace control and configuration parameters occur, (i.e. an ACTIVATE 
MBMS CONTEXT REQUEST message is sent to the UE)) the SGSN shall propagate the trace control and 
configuration parameters to the GGSN (by sending a GTP-CREATE_MBMS_CONTEXT_REQUEST message) and to 
the radio network (by sending a RANAP-CN_INVOKE_TRACE message), if it is defined in the trace control and 
configuration parameters (NE types to trace). The Trace Session activation to UTRAN is described in clauses 4.1.2.4. 

The GGSN shall propagate the trace control and configuration parameters to the BM-SC (by sending a Diameter Gmb 
AAR message) if the BM-SC is defined in the trace control and configuration parameters (NE types to trace). 

When HSS sends the MAP-ACTIVATE_TRACE_MODE message to SGSN it shall include the following parameters 
in the message: 

• IMSI (M). 

• Trace reference (M). 

• Triggering events for SGSN (M), GGSN (M) and BM-SC (M). 

• Trace Depth for SGSN (M), GGSN (M), BM-SC (M) and RNC (M). 
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• List of NE types to trace (M). 

• List of interfaces for SGSN (O), GGSN (O), BM-SC (O) and/or RNC (O). 

When the SGSN sends the GTP-CREATE_MBMS_CONTEXT_REQUEST message to GGSN it shall include the 
following parameters in the message: 

• IMSI or IMEI (SV) (M). 

• Trace reference (M). 

• Trace Recording Session Reference (M). 

• Triggering events for GGSN (M) and BM-SC (M). 

• Trace Depth for GGSN (M) and BM-SC (M). 

• List of interfaces for GGSN (O) and BM-SC (O). 

When the GGSN sends the Diameter Gmb AAR message to the BM-SC it shall include the following parameters in the 

message: 

• IMSI or IMEI (SV) (M). 

• Trace reference (M). 

• Trace Recording Session Reference (M). 

• Triggering events for BM-SC (M). 

• Trace Depth for BM-SC (M). 

• List of interfaces for BM-SC (O). 
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4.1.2.6 



CS Domain activation mechanisms 



The following figure shows the Trace Session activation in the CS domain. The figure is an example of tracing Mobile 
Originating Call. 
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Figure 4.1.2.6.1 : Trace Session Activation in CS domain 

When HSS receives Trace Session activation from the EMS it should store the trace control and configuration 
parameters associated to the Trace Session. 

If the UE registers to the network, by sending a LOCATION UPDATING REQUEST message to the MSC/VLR, the 
MSC Server/VLR updates the location information in the HSS by sending the MAP-UPDATE_LOCATION message to 
the HSS. After receiving the UPDATE_LOCATION message HSS shall propagate the trace control and configuration 
parameters by sending a MAP-ACTIVATE_TRACE_MODE message to the MSC ServerA'LR. 

When the MSC Server/VLR receives the MAP-ACTIVATE_TRACE_MODE message from the HSS, it shall store the 
trace control and configuration parameters. 

When any of the triggering event, defined in the trace control and configuration parameters, occurs (e.g. in case of 
Mobile Originating Call is started (i.e. the MSC Server receives the CM_SERVICE_REQUEST message with service 
type set to originating call establishment)) the MSC Server should propagate the trace control and configuration 
parameters to the MGW (by sending an ADD command with a trace package - see 3GPP TS 29.232 [10]) and to the 
radio network if it is defined in the trace control and configuration parameters (NE types to trace). Trace Session 
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activation for UTRAN is described in clauses 4.1.2.4. In case of inter-MSC Server handover the MSC Server-A should 
propagate the trace control and configuration parameters to the MSC Server-B. 

When HSS sends the MAP-ACTIVATE_TRACE_MODE message to MSC Server it shall include the following 
parameters to the message: 

• IMS! (M). 

• Trace reference (M). 

• Triggering events for MSC Server (M) and MOW (M) . 

• Trace Depth for MSC Server (M), MOW (M) and RNC (M).. 

• List of NE types to trace (M). 

• List of interfaces for MSC Server (O), MOW (O) and/or RNC (O). 

When the MSC Server sends the ADD command with trace package to MGW it shall include the following parameters 
to the message: 

• IMS! or IMEI (SV) (M). 

• Trace reference (M). 

• Trace Recording Session Reference (M). 

• Triggering events for MGW (M). 

• Trace Depth for MGW (M). 

• List of interfaces for MGW (O). 

4.1.2.7 Void 

4.1 .2.8 Tracing roaming subscribers 

If a HPLMN operator activates a Trace Session for a home subscriber, while it (MS) is roaming in a VPLMN, it (HSS) 
may restrict the propagation of the Trace Session activation message to a MSC Server/VLR or to a SGSN located in the 
VPLMN. 

Also, a MSC ServerA'^LR or a SGSN located in a VPLMN may accept any Trace Session activation message(s) coming 
from an HSS located in another PLMN. However, there shall be a capability to reject activations from another PLMN. 

4.1 .2.9 Service Level Tracing for IMS activation mechanisms 
4.1.2.9.1 General 

Figure 4.L2.9.L1 illustrates signalling based activation for service level tracing within a home IM CN SS and a visited 
IM CN SS. An arrow with "Trace Parameter Configuration" represents the availability of the trace functionality at the 
EM for that domain. Similarly, An arrow with "Trace Parameter Propagation" represents the ability to propagate trace 
parameters only for the interfaces indicated. 



£75/ 



3GPP TS 32.422 version 7.2.0 Release 7 



20 



ETSI TS 132 422 V7.2.0 (2007-06) 



Trace Parameter 
Configuration 




HSS 



-Cx- 



-Sh- 



Pararreter 
Propagation 



Parameter 

Propagation 

— Mw 



Mi 



AS 



Parameter 
Propagation 



BGCF 



Trace Parameter 
Configuration 



UE 



EM 
(UE) 



-Cx- 



Parameter 
Propagation 



Parameter 
Propagation 



S-CSCF 



Mr 



Parameter 
Propagation 



MRF 



Parameter 
Propagation 

Gm 



Parameter 
Propagation 



Mg 



Parameter 
Propagation 



i-CSCF 



^.* Parameter 
Propagation 



MGCF 



P-CSCF 



Management Link 
Signalling Link 



Figure 4.1.2.9.1.1 : Overview of Signalling Activation for service level tracing for IMS 

Trace Activation shall be initiated from the Core Network EM only [EM (UE), and EM (HSS)]. 

The EM (UE) and the interactions between the EM (UE) and the UE shall be achieved using OMA Device Management 
[18]. 

When service level tracing for IMS is required for a registered home subscriber in the home IM CN SS Trace Session 
activation shall go to the UE and the HSS. The HSS shall propagate the Trace Session activation to the S-CSCF, I- 
CSCF and the AS. 

The S-CSCF and I-CSCF shall propagate the Trace Session activation to the P-CSCF. The Trace Session activation 
shall be propagated to the MRF, MGCF and BGCF via the S-CSCF. When an IMS NE (i.e. S/I/P-CSCF, AS, HSS, 
MRF, MGCF, BGCF) receives Trace Session activation it shall save the received Trace control and configuration 
parameters and shall start a Trace Session. 

When service level tracing for IMS is required for a registered home subscriber in a visited IM CN SS Trace Session 
activation shall go to the UE and the HSS. The HSS shall propagate the Trace Session activation to the S-CSCF, I- 
CSCF and the AS. The I-CSCF may prohibit the propagation of the Trace Session activation from the home IM CN SS 
to the P-CSCF in the visited IM CN SS. 

Editor's Note: The ability to send Trace session activation to the S/I-CSCF in the home IM CN SS in the situation 
where it is not possible to send Trace Session activation to a UE is FES. 



ETSI 



3GPP TS 32.422 version 7.2.0 Release 7 



21 



ETSI TS 132 422 V7.2.0 (2007-06) 



4.1.2.9.2 



Trace session activation for non-registered UE 



Figure 4.1.2.9.2.1 illustrates the sending of Trace Session activation towards the HSS, S-CSCF, 1-CSCF, AS and 
P-CSCF during the registration of a UE with the IM CN SS. 

As described in 3GPP TS 23.228 [15] for the purposes of signalling flows the user is considered always to be roaming. 
For a user roaming in their home network, the home network shall perform the role of the visited network elements and 
the home network elements. 

NOTE: For detailed information of application level registration procedures for IMS see 3GPP TS 23.228 [15]. 
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Figure 4.1.2.9.2.1 : Trace Session activation for non-registered user 
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When HSS receives Trace Session activation from its EM (Step 1), it shall update the user information associated with 
the user for whom the trace is to be applied (Step 2). The HSS shall store the received trace control and configuration 
parameters (Step 3). At this point a Trace Session shall be started in the HSS. 

When the EM sends the Trace Session activation to the HSS it shall include the following trace and configuration 
parameters in the message: 

Public User Identity (i.e. Identity of user initiating/terminating the service to be traced) (M) 

Service identification (M) 

Trace reference (M) 

Triggering events for HSS (M) 

Trace depth for HSS (M) 

List of NE types (M) 

Triggering events for S-CSCF (M), I-CSCF (M), P-CSCF (M), AS (M), BGCF (M), MRF (M), MGCP (M) 

Trace depth for S-CSCF (M), I-CSCF (M), P-CSCF (M), AS (M), BGCF (M), MRF (M), MGCF (M) 

When the EM sends the Trace Session activation to the HSS it may include the following trace and configuration 
parameters in the message if required: 

• List of interfaces for HSS (O) 

• List of interfaces for S-CSCF (O), I-CSCF (O), P-CSCF (O), AS (O), BGCF (O), MRF (O), MGCF (O). 

As described in 3GPP TS 23.228 [15] when a UE registers with the network by sending a REGISTER message (Steps 4 
to 10), the HSS sends Service Control (user and filter information) to the S-CSCF (Steps 11). It shall also propagate 
trace control and configuration parameters to the S-CSCF. At this point a Trace Session shall be started in the S-CSCF 
(Step 12). 

When the HSS sends the Cx-Put-Response operation to the S-CSCF (see 3GPP TS 29.228 [16]) it shall include the 
following trace and configuration parameters: 

Public User Identity (i.e. Identity of user initiating/terminating the service to be traced) (M) 

Service identification (M) 

Trace reference (M) 

Triggering events for S-CSCF (M) 

Trace depth for S-CSCF (M) 

List of NE types (M) 

Triggering events for I-CSCF (M), P-CSCF (M), BGCF (M), MGCF (M) 

Trace depth for I-CSCF (M), P-CSCF (M), BGCF (M), MGCF (M). 

When the HSS sends the Cx-Put-Response operation to the S-CSCF it may include the following trace and 
configuration parameters if required: 

• List of interfaces for S-CSCF (O) 

• List of interfaces for I-CSCF (O), P-CSCF (O), BGCF (O), MGCF (O) 

Editor's Note: The sending of trace and configuration parameters as part of the Cx-Put-Response operation is for 
FES by CT4. 
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As described in 3GPP TS 23.218 [14] on reception of a REGISTER request, the S-CSCF shall send a third-party 
REGISTER request to the Application Server if the registration request from the user matches a contained trigger as 
downloaded from the HSS (Step 13 and 14). 

As described in 3GPP TS 29.328 [17] the Application Server shall request from the HSS information such as service 
and user related information. In this case, the HSS shall determine that a trace request for the user is active and shall 
return to the Application Server trace control and configuration parameters (Step 16). At this point a Trace Session shall 
be started in the AS (Step 17). 

When the HSS sends the Sh-Pull-Response operation to the AS (see 3GPP TS 29.328 [17]) it shall include the 
following trace and configuration parameters: 

Public User Identity (i.e. Identity of user initiating/terminating the service to be traced) (M). 

Service identification (M) 

Trace reference (M) 

Triggering events for AS (M) 

Trace depth for AS (M) 

List of NE types (M) 

Triggering events for MRF (M) 

Trace depth for MRF (M). 

When the HSS sends the Sh-Pull-Response operation to the AS it may include the following trace and configuration 
parameters if required: 

• List of interfaces for AS (O) 

• List of interfaces for MRF (O) 

Editor's Note: The sending of trace and configuration parameters as part of the Sh-Pull-Response operation is for 
FFS by CT4. 

Upon successful registration the S-CSCF shall return a SIP 200 OK and shall propagate the received trace control and 
configuration parameters to the I-CSCF (Step 18). At this point a Trace Session shall be started in the I-CSCF (Step 19). 

When the S-CSCF sends the 200 OK (Register) message to the I-CSCF (see 3GPP TS 24.228 [15]) it shall include the 
following trace and configuration parameters: 

Public User Identity (i.e. Identity of user initiating/terminating the service to be traced) (M). 

Service identification (M) 

Trace reference (M) 

Trace depth for I-CSCF (M) 

Triggering events for I-CSCF (M) 

List of NE types (M) 

Triggering events for P-CSCF (M) 

Trace depth for P-CSCF (M) 

When the S-CSCF sends the 200 OK (Register) message to the I-CSCF it may include the following trace and 
configuration parameters if required: 

• List of interfaces for I-CSCF (O) 

• List of interfaces for P-CSCF (O) 



ETSI 



3GPP TS 32.422 version 7.2.0 Release 7 24 ETSI TS 1 32 422 V7.2.0 (2007-06) 

If the P-CSCF resides in the same (i.e. home IM CN SS) network as the I-CSCF, the I-CSCF forwards the SIP 200 OK 
and shall propagate the retrieved trace control and configuration parameters to the P-CSCF (Step 20). At this point a 
Trace Session shall be started in the P-CSCF (Step 21). 

When the I-CSCF sends the 200 OK (Register) message to the P-CSCF (see 3GPP TS 24.228 [15]) it shall include the 
following trace and configuration parameters: 

Public User Identity (i.e. Identity of user initiating/terminating the traced service) (M) 

Service identification (M) 

Trace reference (M) 

Trace depth for P-CSCF (M) 

Triggering events for P-CSCF (M) 

List of NE types (M) 

When the I-CSCF sends the 200 OK (Register) message to the P-CSCF it may include the following trace and 
configuration parameters if required: 

• List of interfaces for P-CSCF (O). 

If the P-CSCF resides in a different (i.e. visited IM CN SS) network as the I-CSCF, the I-CSCF forwards the SIP 200 
OK and may propagate the retrieved trace control and configuration parameters to the P-CSCF. If the P-CSCF is in a 
different network than the I-CSCF and the sending of trace control and configuration parameters from the home IM CN 
SS to the visited IM CN SS is prohibited then the I-CSCF shall restrict the sending of the trace control and 
configuration parameters. 

The P-CSCF shall forward the SIP 200 OK to the UE. The P-CSCF shall not send the retrieved trace control and 
configuration parameters. 
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4.1.2.9.3 



Trace session activation for a registered UE 



Figure 4.1.2.9.3.1 illustrates the sending of Trace Session activation towards the HSS, S-CSCF, 1-CSCF, AS and P- 
CSCF during the re-registration of a UE with the IM CN SS. 

As described in 3GPP TS 23.228 [15] periodic application level re-registration is initiated by the UE either to refresh an 
existing registration or in response to a change in the registration status of the UE. Re-registration follows the same 
process as that defined for registration of a non-registered user. 
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Figure 4.1.2.9.3.1 : Trace Session activation for registered UE 

When HSS receives Trace Session activation from its EM (Step 1), it shall update the user information associated with 
the user for whom the trace is to be applied (Step 2). The HSS shall store the received trace control and configuration 
parameters (Step 3). At this point a Trace Session shall be started in the HSS. 

When the EM sends the Trace Session activation to the HSS it shall include the trace and configuration parameters as 
described in clause 4.1.2.9.2. 

Prior to expiry of the agreed registration timer, the UE initiates a re-registration by sending a REGISTER message. 
The subsequent steps of re-registration of the UE as described in 3GPP TS 23.228 [15] and the signalling flow steps as 
described in subclause 4.1.2.9.2 apply. 
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The IM CN SS shall request a re-authentication of a registered UE when Trace Session activation is required before the 
UE performs a periodic re-registration, and when the subscription status of the registered UE is not to be affected. 

Following a network initiated re-authentication, the UE shall re-register with the IM CN SS and the procedures 
described for Trace Session activation for a registered UE shall apply. 



4.1.2.9.4 



Trace session activation at the UE 



Figure 4.1.2.9.4.1 illustrates the sending of Trace Session activation from the Device Management Server (DMS) to a 
UE and the subsequent propagation of a SIP message including a start trigger event from the UE and the P-CSCF. 

Editor's note: The exact OMA Device Management enabler is FFS. 
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Figure 4.1.2.9.4.1 : Trace Session activation at a UE 

A management session shall be established (Step 1) in accordance with OMA Device Management [18]. When a UE 
receives Trace Session Activation (Step 2) as part of the received management operation it shall store the Trace Control 
and configuration parameters, and may (e.g. depending on Operator conditions) start a trace session (Step 3). 

When any of the triggering events occur at the UE (e.g. the service to be traced from the traced UE is initiated), and 
when the condition(s) as defined by the trace control and configuration parameters within the received management 
operation occur, the UE shall start a trace recording (Step 4). As described in subclause 4.2.3.5 the UE shall include in 
the outgoing SIP (service) signalling message (e.g. INVITE) a Start Trigger Event (Step 5). 
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4.1 .3 Management deactivation 

4.1 .3.1 UTRAN deactivation mechanisms 

When last Trace session is requested to be ended for an IMEI(S V) or a list of IMEI(S V), the RNC shall send the 
requested IMEI(SV)/list of lMEI(SV)s in 'Uplink Information Exchange Request' to the interacting MSC Server(s) and 
SGSN(s). The MSC Servers and SGSNs shall remove the requested IMEI(SV)s for the RNC in question. 

4.1 .3.2 PS Domain deactivation mechanisms 

When a SGSN, GGSN or BM-SC receives a Trace Session Deactivation from its EM, the Trace Session identified by 
the Trace Reference, shall be deactivated in SGSN/GGSN/BM-SC. 

If a Trace Recording Session is active at the time of receiving a Trace Session deactivation from the EM, the 
SGSN/GGSN/BM-SC may choose to continue the Trace Recording Session till it ends gracefully or may stop it 
immediately. In all cases, the SGSN/GGSN/BM-SC shall deactivate the requested Trace Session immediately at the end 
of the Trace Recording Session. 

4.1 .3.3 CS Domain deactivation mechanisms 

When a MSC Server receives a Trace Session Deactivation from its EM, the Trace Session identified by the Trace 
Reference, shall be deactivated in MSC Server. 

If a Trace Recording Session is active at the time of receiving a Trace Session deactivation from the EM, the MSC 
Server may choose to continue the Trace Recording Session till it ends gracefully or may stop it immediately. In all 
cases, the MSC Server shall deactivate the requested Trace Session immediately at the end of the Trace Recording 
Session. 

4.1 .3.4 IP Multimedia Subsystem deactivation mechanisms 

When a S-CSCF/P-CSCF receives a Trace Session deactivation from the EM, the Trace Session identified by the Trace 
Reference, shall be deactivated. 

If a Trace Recording Session is active at the time of receiving a Trace Session deactivation from the EM, the S- 
CSCF/P-CSCF may choose to continue the Trace Recording Session till it ends gracefully or may stop it immediately. 
In all cases, the S-CSCF/P-CSCF shall deactivate the requested Trace Session immediately at the end of the Trace 
Recording Session. 
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The following figure illustrates how the Trace Session is deactivated when a Trace Recording Session is going on (e.j 
a SIP INVITE method is being traced in S-CSCF). 
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Figure 4.1.3.4.1 : Trace session deactivation in IIVIS 
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4.1 .4 Signalling deactivation 

4.1.4.1 General 

In Signalling deactivation, the Trace Deactivation shall always be carried out from the Core Network EM only [EM 
(PS), EM (CS), and EM (HSS) are generally considered to be in the Core Network. A Core Network EM can be any of 
these or their combinations]. In case of home subscriber trace (i.e. in the HPLMN) the Trace Session deactivation shall 
go to the HSS, MSC Server/VLR, or SGSN. In case of foreign subscriber trace (i.e. the HPLMN operator wishes to 
deactivate tracing on foreign subscribers roaming in his PLMN) the Trace Session deactivation shall go the MSC 
ServerA'LR or SGSN. The Management System shall deactivate the Trace Session in the same NE where it activated 
the Trace Session. 

When an HSS receives a Trace Session deactivation from its Management system, it shall deactivate the active Trace 
Session corresponding to the Trace Reference received in the deactivation message. The HSS shall delete all trace 
control and configuration parameters associated with this Trace Session. If a Trace Recording Session is active at the 
time of receiving a Trace Session deactivation message from the EM, the HSS may choose to continue the Trace 
Recording Session till it ends gracefully or may stop it immediately. In all cases, the HSS shall deactivate the requested 
Trace Session immediately at the end of the Trace Recording Session. 

4.1.4.2 UTRAN deactivation mechanisms 

When RNC receives the CN_DEACTIVATE_TRACE message it shall deactivate the Trace Session for the indicated 
Trace Reference in the CN_DEACTIVATE_TRACE message. In case of simultaneous CS/PS connections, the trace 
session for the indicated trace reference shall be closed upon reception of the CN DEACTIVATE TRACE message 
from any of the CN domain, whether it was the one which initiated trace session activation or not. 

The Trace Session is also deactivated in the RNC when the lu connection to the Core Network is released. 

If CN_INVOKE_TRACE message is received for only one lu connection (either CS or PS) the Trace Session shall be 
deactivated in the RNC when the IU_RELEASE_COMMAND message is received from the Core Network for that lu 
connection where the CN_INVOKE_TRACE message is sent. 

The following figure shows this behaviour: 
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Figure 4.1.4.2.1 : Trace session deactivation (Signalling) in UTRAN 1 

If CN_INVOKE_TRACE message is received by the RNC for both lu-CS and lu-PS connection with the same Trace 
Reference number than the Trace Session shall not be deactivated in the RNC when any of the lu connection is released 
(when the first IU_RELEASE_COMMAND message is received). The Trace Session shall be deactivated when the 
second lu connection is released (the second IU_RELEASE_COMMAND message is received). The following figure 
shows the situation. 
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Figure 4.1.4.2.2: Trace session deactivation (Signalling) in UTRAN 2 
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Interaction with Soft-handover 

The Trace Session should be deactivated in a Drift RNC when the DRNC receives the IUR_DEACTIVATE_TRACE 
message or the lur connection is released. 

When an RNC deactivates a Trace Session the Trace Recording Session shall also be stopped at the same time. 

NOTE: In RNC the Trace Session and the Trace Recording Session always the same. 

4.1 .4.3 PS Domain deactivation mechanisms 

When an HSS receives a Trace Session deactivation from the Management System it shall send a 
MAP_DEACTIVATE_TRACE_MODE message to the SGSN. 

When the SGSN receives a MAP_DEACTIVATE_TRACE_MODE message it shall deactivate the Trace Session 
identified by the Trace reference received in the MAP_DEACTIVATE_TRACE_MODE message. 

If a Trace Recording Session is active at the time of receiving a deactivation message (in SGSN it is the MAP- 
DEACTIVATE_TRACE_MODE, in GGSN it is the GTP Update PDP Context Request or the Update MBMS Context 
Request, in BM-SC it is the Diameter Gmb STR message), the SGSN and/or the GGSN and/or the BM-SC may 
choose to continue the Trace Recording Session till it ends gracefully or may stop it immediately. In all cases, the 
SGSN/GGSN/BM-SC shall deactivate the requested Trace Session immediately at the end of the Trace Recording 
Session. When the SGSN deactivates the Trace Session, it shall delete all trace control and configuration parameters 
associated with the corresponding Trace Session. 

If SGSN deactivates the Trace Session during the Trace Recording Session, the SGSN should deactivate the trace to the 
RNC by using the CN_DEACTIVATE_TRACE RANAP message and should deactivate the trace to the GGSN by 
sending the GTP Update PDP Context Request or the Update MBMS Context Request message with Trace Activity 
Control set to Trace Deactivation. 

If the GGSN deactivates the Trace Session during the Trace Recording Session, the GGSN should deactivate the trace 
to the BM-SC (by sending a Diameter Gmb STR message). 

4.1.4.4 CS Domain deactivation mechanisms 

When an HSS receives Trace Session deactivation from the Management System it shall send a 
MAP_DEACTIVATE_TRACE_MODE message to the MSC Server. 

When the MSC Server receives a MAP_DEACTIVATE_TRACE_MODE message it shall deactivate the Trace Session 
identified by the Trace reference received in the MAP_DEACTIVATE_TRACE_MODE message. 

If a Trace Recording Session is active at the time of receiving a MAP_DEACTIVATE_TRACE_MODE message from 
the HSS, the MSC Server may choose to continue the Trace Recording Session till it ends gracefully or may stop it 
immediately. In all cases, the MSC Server shall deactivate the requested Trace Session immediately at the end of the 
Trace Recording Session. When the MSC Server deactivates the Trace Session it shall delete all trace control and 
configuration parameters associated with the corresponding Trace Session. . 

If MSC Server deactivates the Trace Session during a Trace Recording Session, it should deactivate the trace to the 
RNC by sending the CN_DEACTIVATE_TRACE RANAP message and should deactivate the trace to the MGW. 

4.1.4.5 Void 

4.1 .4.6 Service Level Trace in IMS deactivation mechanisms 
4.1.4.6.1 General 

When an IMS NE (i.e. S/I/P-CSCF, AS, HSS, MRF, MGCF, BGCF) receives Trace Session deactivation the Trace 
Session, as identified by the Trace Reference, shall be deactivated. 

If a Trace Recording Session(s) within the Trace session is active at the time of receiving a Trace Session deactivation, 
the IMS NE may stop the trace recording session(s) immediately or it may choose to continue the Trace Recording 
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Session(s) till the session(s) ends gracefully (e.g. the SIP session ends after a specific period of time, or upon 
completion of a SIP session and the reception of a SIP BYE). 

In all cases, the IMS NE shall deactivate the requested Trace Session immediately at the end of the Trace Recording 
Session(s). When the IMS NE deactivates the Trace Session, it shall delete all associated trace control and configuration 
parameters associated with that Trace Session. 

4.1 .4.6.2 Trace session deactivation at an IMS NE 

4.1 .4.6.2.1 Trace session deactivation propagated by EM 

Trace Session deactivation may be initiated from the Core Network EM only [EM (UE), and EM (HSS)]. The same EM 
that initiated Trace Session activation shall initiate a Trace Session deactivation in the same Network Element (NE). 

When Trace Session deactivation is required for a registered home subscriber in the home IM CN SS, Trace Session 
deactivation shall go to the UE and the HSS. The HSS shall propagate the Trace Session deactivation to the S-CSCF, I- 
CSCF, and the AS. The S-CSCF and I-CSCF shall propagate the Trace Session deactivation to the P-CSCF. The Trace 
Session deactivation shall be propagated to the MRF, MGCF and BGCF via the S-CSCF. 

When Trace deactivation is required for a registered home subscriber in a visited IM CN SS, Trace Session deactivation 
shall go to the UE and the HSS. The HSS shall propagate the Trace Session deactivation to the S-CSCF, I-CSCF and 
the AS. 

Depending on whether the I-CSCF had previously propagated a Trace Session Activation to the P-CSCF serving the UE 
(see subclause 4.1.2.9.2) where Trace is to be initiated the I-CSCF may propagate the Trace Session deactivation to the 
P-CSCF. 

4.1 .4.6.2.2 Trace session deactivation following a Triggering event 

An Active Trace Session may be deactivated at an IMS NE following the detection of a Stop Triggering Event, e.g. 
Trace Session expiry time. 

In the case where there is one or more active Trace Recording Sessions, the IMS NE shall deactivate the Trace Session 
immediately following the detection of a Stop Triggering Event associated for each of the Trace Recording Session(s), 
e.g. following the detection of SIP final response or a SIP Request Failure 

When the IMS NE deactivates the Trace Session Stop Triggering Event, it shall delete all associated trace control and 
configuration parameters associated with that Trace Session. 

4.1 .4.6.2.3 Trace session deactivation initiated directly by an EM 

When required, an active Trace Session at an IMS NE may be deactivated directly by it's EM. The Management based 
Trace Session deactivation mechanism (see clause 4.1.1) shall be used for this purpose. 

4.1 .4.6.3 Trace session deactivation at the UE 

The EM (UE) and the interactions between the EM (UE) and the UE shall be achieved using OMA Device Management 
[18]. 

Figure 4.1.4.6.3.1 illustrates the sending of Trace Session Deactivation from the Device Management Server (DMS) to 
aUE. 

Editor's note: The exact OMA Device Management enabler is FFS. 
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Figure 4.1.4.6.3.1 : Trace session deactivation at a UE 

Trace Session deactivation shall be initiated from the Device Management Server (DMS). The same DMS that initiated 
Trace Session activation shall initiate a Trace Session deactivation in the same UE (Step 1). 

When a UE receives Trace Session Deactivation as part of the received management operation from its DMS (Step 2) it 
may deactivate the Trace Session (Step 3). 

If a Trace Recording Session(s) within the Trace session is active at the time of receiving a Trace Session deactivation, 
the UE may stop the trace recording session(s) immediately (see note), or it may choose to continue the Trace 
Recording Session(s) until the session(s) end gracefully (e.g. the SIP session ends after a specific period of time, or 
upon completion of a SIP session and the reception of a SIP BYE). 

NOTE: When the Trace session is stopped the UE may deactivate or delete its management operation. 
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4.2 Trace recording session Start / Stop triggering 

4.2.1 General 

Editor's Note: For further study. 

The Trace Session activation contains the triggering events parameter. The actual start/stop triggering events 
corresponding to the values of the triggering events parameter are defined in triggering events tables in sub-clause 5.1 in 
the present document. 

4.2.2 Starting a trace recording session - management based 

4.2.2.1 UTRAN starting mechanisms 

In an RNC, a Trace Recording Session should start after the reception of the CN_IN VOKE_TRACE message from the 
CN and if some activities have been started on the interfaces that have been requested to be traced. The RNC shall 
record those signalling messages in the interfaces that are defined in the list of interfaces parameter. Trace depth defines 
whether entire signalling messages or just some IBs needs to be recorded. 

The RNC may not start a Trace Recording Session if there are insufficient resources available for the recording. 

When RNC starts a Trace Recording Session it shall assign a Trace Recording Session Reference for the Trace 
Recording Session. 

4.2.2.2 PS Domain starting mechanisms 

In a SGSN/GGSN/BM-SC, a Trace Recording Session should start after the reception of a Trace Session Activation 
from EM and if any of the defined start triggering events occur. During the Trace Recording Session, the 
SGSN/GGSN/BM-SC shall record those signalling messages in the interfaces that are defined in the list of interfaces 
parameter. The Trace Depth parameter defines whether entire signalling messages or just some IBs need to be recorded. 

The IMSI and IMEISV shall be available in the SGSN, in the GGSN and in the BM-SC for at least those connections 
which shall be traced. 

The SGSN/GGSN/BM-SC may not start a Trace Recording Session if there are insufficient resources available for the 
recording. 

If the SGSN/GGSN/BM-SC receives the Trace Session Activation during an established session (e.g. during an active 
PDP context or an active MBMS context), it may start the Trace Recording Session immediately. However, if any of the 
start triggering events occur in the SGSN/GGSN/BM-SC after receiving the Trace Session Activation, it shall start the 
Trace Recording Session. 

When a Trace Recording Session is started, the SGSN/GGSN/BM-SC shall assign a Trace Recording Session 
Reference for the Trace Recording Session. 

4.2.2.3 CS Domain starting mechanisms 

In a MSC Server, a Trace Recording Session shall start after the reception of a Trace Session Activation from EM and if 
any of the defined start triggering events occur. During the Trace Recording Session, the MSC Server shall record those 
signalling messages in the interfaces that are defined in the list of interfaces parameter. The Trace Depth parameter 
defines whether entire signalUng messages or just some lEs needs to be recorded. 

The IMSI and the IMEISV shall be available in the MSC Server for at least those connections which shall be traced. 

The MSC Server may not start a Trace Recording Session if there are insufficient resources available for the recording. 

If the MSC Server receives the Trace Session Activation during an established call, it may start the Trace Recording 
Session immediately. However, if any of the start triggering events occurs in MSC Server after receiving the Trace 
Session Activation, it shall start the Trace Recording Session. 
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When a Trace Recording Session is started, the MSC Server shall assign a Trace Recording Session Reference for the 
Trace Recording Session. 

4.2.2.4 IP Multimedia Subsystem starting mechanisms 

Editor's Note: For further study. 

4.2.3 Starting a trace recording session - signalling based 
4.2.3.1 UTRAN starting mechanisms 

In an RNC the Trace Recording Session will always be the same as the Trace Session as no triggering events are 
defined in UTRAN. Therefore a Trace Recording Session should be started in an SRNC when the SRNC receives the 
CN_INVOKE_TRACE message from the Core Network and if some activities have been started on the interfaces that 
have been requested to be traced. If the SRNC receives a second CN_IN VOKE_TRACE message from the CN with the 
same Trace Reference that have been received in the first CN_INVOKE_TRACE message, a new Trace Recording 
Session should not be started as it is already started. 

The CN_INVOKE_TRACE message that is received from the Core Network (MSC Server or SGSN) contains the 
following information: 

Trace Reference 

UE identity (IMSI or IMEI(SV) 

Trace Recording Session Reference 

Trace Depth for RNC 

List of interfaces for RNC 

If the SRNC does not have enough resources it may not start a Trace Recording Session. 

The Trace Recording Session Reference shall be the same as received in the CN_INVOKE_TRACE message. 

In a DRNC the Trace Recording Session should be started when the DRNC receives the IUR_INVOKE_TRACE 
message. If the DRNC does not have enough resources it may not start a Trace Recording Session. 

The Trace Session is activated to the RNC by sending a CN_INVOKE_TRACE message from the CN (MSC Server or 
SGSN). When RNC receives the CN_INVOKE_TRACE message it should immediately start a Trace Session and a 
Trace Recording Session according to the trace control and configuration parameters received in the 
CN_INVOKE_TRACE message. 

If there are not enough resources in RNC to start a Trace Recording Session, the RNC may reject to start a Trace 
Recording Session. However the RNC shall start the Trace Session. 

In the case RNC receives multiple CN INVOKE TRACE messages for the same subscriber or equipment (e.g. 
simultaneous CS/PS connections): 

If the Trace Reference is equal to an existing one, a new trace session and trace recording session shall not be 
started; 

If the Trace Reference is not equal to an existing one, a new trace session and trace recording session may be 
started. 

The following figure shows an example for a CS call how the Trace Session is activated to RNC. In the example it is 
assumed that there is no PS connection at all during the CS call. 
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Figure 4.2.3.1.1 : Starting a Trace Recording Session (Signalling) in UTRAN 

Interaction with soft-lnandovers 

If the subscriber or equipment, which is traced, makes a soft handover the SRNC should propagate the trace control and 
configuration parameters further to the DRNC by using the IUR_INVOKE_TRACE message. When the DRNC 
receives the IUR_INVOKE_TRACE message it should immediately start a Trace Session and a Trace Recording 
Session according to the trace control and configuration parameters received in the IUR_INVOKE_TRACE message. 

If there are insufficient resources in the DRNC, the DRNC may not start a Trace Recording Session. 

The Trace Recording Session Reference sent by the SRNC to the DRNC shall be the same what SRNC has received in 
the CN_INVOKE_TRACE message from the CN. 

Interaction witin Relocation 

If the tracing shall continue also after the relocation has been performed, the CN Invoke Trace procedure shall be re- 
initiated from the CN towards the future SRNC after the Relocation Resource Allocation procedure has been executed 
successfully. 
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4.2.3.2 PS Domain starting mechanisms 

In SGSN/GGSN/BM-SC a Trace Recording Session should start after the reception of a Trace Session Activation 
message (in SGSN it is the MAP-ACTIVATE_TRACE_MODE, in GGSN it is the GTP-Create PDP Context request or 
Update PDP Context request, in BM-SC it is the Diameter Gmb AAR message) and if any of the defined start 
triggering events occur. During the Trace Recording Session, the SGSN/GGSN/BM-SC shall record the signalling 
messages in the interfaces that are defined in the list of interfaces parameter. The Trace Depth parameter defines 
whether entire signalling messages or just some IBs need to be recorded. 

The SGSN/GGSN/BM-SC may not start a Trace Recording Session if there are insufficient resources available for the 
recording. 

In case of an established session, the SGSN may start the Trace Recording Session immediately after the reception of 
the Trace Session Activation message. However, if any of the start triggering events occurs in SGSN after receiving the 
Trace Session activation message, it shall start the Trace Recording. 

When a Trace Recording Session is started in SGSN, it shall assign a Trace Recording Session Reference for the Trace 
Recording Session. When the SGSN propagates the Trace control and configuration parameters to GGSN or to UTRAN 
(I.e. activates a Trace Session in GGSN/UTRAN), it shall include the assigned Trace Recording Session Reference in 
the Trace Session Activation message. When an SGSN starts a Trace Recording Session and the list of NE types 
parameter requires GGSN tracing, it shall send the GTP- Update PDP Context Request or Create PDP Context Request 
message for activating the Trace Session to GGSN. When a GGSN starts a Trace Recording Session and the list of NE 
types parameter requires BM-SC tracing, it shall send a Diameter Gmb AAR message to the BM-SC in order to activate 
a Trace Session in the BM-SC. Also, when an SGSN starts a Trace Recording Session and the list of NE types 
parameter requires RNC tracing, it shall send the CN_INVOKE_TRACE message to the RNC in order to activate a 
Trace Session in RNC. In both cases the Trace Session and the Trace Recording Session in the receiving NE should 
start at the same time. 

In case of SRNS relocation the SGSN shall send the CN_INVOKE_TRACE message to the new SRNC after the 
successful Relocation Resource Allocation procedure. 

SGSN has to find the identity of the mobile before it activates a Trace Session towards other NE. The IMEI(SV) can be 
got from the Mobile by using the Identification procedure on the lu interface. 

When the SGSN sends the Trace Session activation (CN_INVOKE_TRACE) message to RNC it shall include the 
following parameters to the message: 

• IMSI or IMEI (SV) (M). 

• Trace reference (M). 

• Trace Recording Session Reference (M). 

• Trace Depth (M). 

• List of interfaces (O). 
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4.2.3.3 CS Domain starting mechanisms 

In MSC Server/MGW a Trace Recording Session should start after the reception of a Trace Session Activation message 
(MAP- ACTIVATE TRACE MODE in MSC Server and ADD/MOD command with Trace package in MOW) and if 
any of the defined start triggering events occur. During the Trace Recording Session the MSC Server/MGW shall 
record the signalling messages in the interfaces that are defined in the list of interfaces parameter. The Trace Depth 
parameter defines whether entire signalling messages or just some lEs need to be recorded. 

The MSC Server may not start a Trace Recording Session if there are insufficient resources available for the recording. 

In case of an established call, the MSC Server may start the Trace Recording Session immediately after the reception of 
the MAP-ACTIVATE_TRACE_MODE message. However, if any of the start triggering events occur in the MSC 
Server after receiving the Trace Session activation message, it shall start the Trace Recording Session. 

When a Trace Recording Session is started in MSC Server, it shall assign a Trace Recording Session Reference for the 
Trace Recording Session. When the MSC Server propagates the Trace control and configuration parameters to MGW or 
to UTRAN (I.e. activates a Trace Session in MGW/UTRAN) it shall include the assigned Trace Recording Session 
Reference in the Trace Session Activation message. 

When an MSC Server starts a Trace Recording Session and the list of NE types parameter requires MGW tracing, it 
shall send the ADD/MOD command with trace package to MGW in order to activate the trace in MGW. Also, when an 
MSC Server starts a Trace Recording Session and the list of NE types parameter requires RNC tracing, it shall send the 
CN_INVOKE_TRACE message to the RNC. In both cases the Trace Session and the Trace Recording Session in the 
receiving NE should start at the same time. 

MSC Server has to find the identity of the mobile before it activates a Trace Session towards other NE. The IMEI(SV) 
can be got from the Mobile by using the Identification procedure on the lu interface. 

In case of SRNS relocation the MSC Server shall send the CN_INVOKE_TRACE message to the new SRNC after the 
successful Relocation Resource Allocation procedure. The following figure shows an example how the Trace Session is 
activated with CN_INVOKE_TRACE message in case of relocation. 
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Figure 4.2.3.3.1 : Starting a Trace Recording Session (Signalling) in CS Domain 

When the new SRNC receives the CN_INVOKE_TRACE message it should start immediately a Trace Session and a 
Trace Recording session according to the trace control and configuration parameters received in the 
CN_INVOKE_TRACE message. The Trace Session shall automatically be deactivated in the old RNC when the lu 
connection is released. 

When the MSC Server sends the Trace Session activation (CN_INVOKE_TRACE) message to RNC it shall include the 
following parameters to the message: 

• IMSI or IMEI (SV) (M). 

• Trace reference (M). 

• Trace Recording Session Reference (M). 

• Trace Depth (M). 

• List of interfaces to trace (O). 
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4.2.3.5 Service level tracing for IMS starting mechanism 



4.2.3.5.1 
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A trace recording session should start when there is an active trace session and when an appropriate start triggering 
event occurs. Figure 4.2.3.5.1.1 illustrates the initiation of a trace recording session at the UE, P-CSCF and S-CSCF 
within an originating network when any of the defined triggering events as defined in Trace Session Activation occur. 
When a triggering event occurs in the UE (Step 1) it includes in the outgoing SIP (service) signalling message a service 
level tracing Start Triggering Event (Step 2) and starts a trace recording session (Step 3). When the P-CSCF receives 
the SIP (service) signalling message containing the Start Triggering Event it authenticates the received Start Triggering 
Event (step 4) and starts its trace recording session (Step 5). The P-CSCF forwards the SIP (service) signalling message 
containing the Start Triggering Event to the S-CSCF (Step 7) and starts its trace recording session (Step 8). 



Originating network 



UE#1 



P-CSCF#1 



Trace Session 
activated 



Trace Session 
activated 



1 . Session initiated 
(Start Trigger Event) 



2. INVITE 



(Start Trigger Event) 



3. Trace Recording 
Session started 



4. Authientication of 
Start Trigger Event 



5. Trace Recording 
Session started 



6. 100 Trying 



S-CSCF#1 



Trace Session 
activated 



7 INVITE 



(Start Trigger Event) 



8. Trace Recording 
Session started 



Figure 4.2.3.5.1.1a: Starting a Trace Recording Session within originating network 

Figure 4.2.3.5.1.2 illustrates the initiation of a trace recording session at the AS, I-CSCF, HSS, S-CSCF, P-CSCF and 
UE within the terminating network when any of the defined triggering events as defined in Trace Session Activation 
occur. 

NOTE: All origination, termination and S-CSCF to CSCF procedures as described in 3GPP TS 23.228 [15] apply. 



£75/ 



3GPP TS 32.422 version 7.2.0 Release 7 



42 



ETSI TS 132 422 V7.2.0 (2007-06) 



Originating network 



Terminating network 



S-CSCF#1 



AS 



l-CSCF#2 



S-CSCF #2 



HSS 



P-CSCF#2 



UE#2 



Trace Session activated 



7. INVITE. 



(Start Trigger Eve nt) 

/' 8. Started Trace 
'x Recording session 



9. 100 Trying 



10. Service control 



11. INVITE 
(Start Trigger Even* 



14. INVITE 
(Start Trigger EventI 
15. 



34. 183 Session 



Progress 



12. Started Trace 
Recording session 



13. 100 Trying 



(Start T 



33. 183 Session 



Progress 



INVITE 



igger Event) 



1 6. Started Trace 
Recording session 



17. 100 Trying 



20. Cx User Location Response 



(Start Trigger 
21. INVITE 



(Start Trigger Event) 



18. Cx User LDcation Query 



(Start Trigger Event) 



1 9. Started Trace 
Recording session 



Event) 



22. Started Trace 
Recording session 



23. 100 Trying 



32. 183 Session 



Progress 



24. INVITE 



(Start Trigger Event) 



26. 100 Try 



ng 



25. Started Trace 
Recording session 



27. INVITE 
(Start Trigger Event) 



28. Started Trace 
Recording session 



31. 18:! Session 



29. 100 Trying 



30. 183 Session 
Progress 



Progress 
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When S-CSCF#1 receives the SIP (service) signalhng message containing the Service Level Tracing Start Trigger 
Event (step 7) it shall start a trace recording session (Step 8). Based on the service control information (step 10) S- 
CSCF#1 forwards the SIP (service) signalling message containing the Start Trigger Event to the Application Server 
(Step 11). 

On reception of the SIP INVITE the Application Server adds, removes, or modifies the header contents contained in the 
SIP INVITE (see 3GPP TS 23.218) and proxies the SIP INVITE together with the Start Trigger Event back to S- 
CSCF#1 (Step 14). The Application Server also starts a trace recording session (Step 12). 

S-CSCF#1 forwards the SIP INVITE containing the service level tracing Start Trigger Event request to I-CSCF#2 (Step 
15). At this point the I-CSCF starts a trace recording session Step 16). 

I-CSCF#2 initiates a query to the HSS for the current location of the terminating user (UE#2) and includes in the Cx- 
User Location procedure the service level tracing Start Trigger Event (Step 20). 

When the HSS receives the query for the current location and an associated Start Trigger Event it shall start a trace 
recording session (Step 19) and returns to the I-CSCF#2 the address of the current S-CSCF (S-CSCF#2) for the 
terminating user and the service level tracing Start Trigger Event (20). 

I-CSCF#2 forwards the SIP INVITE containing the Start Trigger Event to the S-CSCF (S-CSCF#2) that will handle the 
session termination. When the S-CSCF receives the SIP INVITE containing the Start Trigger Event it starts a trace 
recording session (Step 21). 

The S-CSCF forwards the SIP INVITE containing the Start Trigger Event to the P-CSCF (P-CSCF#2). When the P- 
CSCF receives the SIP INVITE containing the Start Trigger Event it starts a trace recording session (Steps 24 and 25). 

The P-CSCF forwards the SIP INVITE containing the Start Trigger Event to the terminating UE (UE#2). When the 
terminating UE receives the SIP INVITE containing the Start Trigger Event it starts a trace recording session (Step 28). 

The continuation of the termination procedures is as defined in 3GPP TS 23.228 [15]. 

4.2.3.5.2 Starting mechanism at the UE 

For a UE that has an active trace session (see subclause 4.1.2.9.4) one or more trace recording session(s) (e.g. to allow 
the tracing for several different simultaneous services) shall be started when any of the defined triggering events occur 
at the UE, and when the condition(s) as defined by the trace control and configuration parameters within the received 
management operation occur. 

Editor's note: The exact OMA Device Management enabler is FES. 

A Trace recording session(s) may be initiated at an originating UE when: 

1) The UE detects the initiation of the specified service to be traced. The service may be initiated either by the 
end user or by an application. 

The triggering events at a terminating UE include: 

1) The UE detects the initiation of the specified service to be traced. The service may be initiated either by the 
end user or by an application. 

2) The UE detects the reception of an incoming SIP message containg the service level tracing Start Triggering 
Event. 

A Trace recording session(s) may be initiated at a UE (both originating and terminating) when it detects a start trigger 
event initiated directly by the Device Management server for the purpose of allowing not only SIP information related 
to the service to be traced, but also information relating to the processes performed by the UE to support the 
initialization of the service. 

Upon the detection of a triggering event the UE shall include in the appropriate outgoing SIP (service) signalling 
message (i.e. the outgoing signalling messages associated with the service to be traced) a service level tracing Start 
Triggering Event. 
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4.2.3.5.3 Starting mechanism at the IMS NE 

For an IMS NE (i.e. S/I/P-CSCF, AS, HSS, MRF, MGCF, BGCF) that has an active trace session (see subclause 
4.1.2.9) a trace recording session should be started when it receives in an incoming SIP (service) signalling message 
containing a service level tracing Start Triggering Event and when the information contained within the service level 
tracing Start Triggering Event matches the information received by the IMS NE during trace session activation. The 
IMS NE shall also start the recording of signalling messages in the interfaces that are defined in the list of received 
interfaces parameter. 

An IMS NE (i.e. S/I/P-CSCF, AS, HSS, MRF, MGCF, BGCF) that receives an incoming SIP (service) signalling 
message containing a service level tracing Start Triggering Event should forward in an appropriate outgoing SIP 
(service) signalling message (i.e. outgoing signalling messages associated with the service being traced) the same 
service level tracing Start Triggering Event (i.e. service level tracing Start Triggering Event with the same trace 
reference). 

When an IMS NE has an active trace session and trace recording session, and when an incoming SIP (service) 
signalling message is part of an existing dialog or standalone transaction and contains a service level tracing Start 
Trigger Event the IMS NE shall determine that an active Trace Recording Session exists and shall not start a new Trace 
Recording Session. 

Depending on operator policy, a HSS may forward the service level tracing Start Triggering Event to an external AS 
(see 3GPP TS 23.218 [14]). In the case of a terminating session a S-CSCF or I-CSCF may forward the service level 
tracing Start Triggering Event to a P-CSCF in a visited IM CN SS. A P-CSCF shall send a service level tracing Start 
Triggering Event to a terminating UE. 

When a P-CSCF receives a SIP (service) signalling message containing a service level tracing Start Triggering Event 
from a UE it shall authenticate the Start Triggering Event by comparing the information contained within the received 
service level tracing Start Triggering Event (see subclause 5.1a) either against the information it received within the 
Start Trace activation message or by requesting information from the I-CSCF or S-CSCF. If the received service level 
tracing Start Triggering Event is authenticated by the P-CSCF it should start a trace recording session and shall forward 
the service level tracing Start Triggering Event in the appropriate outgoing SIP (service) signalling message. 

If the authentication of the incoming service level tracing Start Triggering Event fails the P-CSCF shall not start a trace 
recording session and shall not forward the service level tracing Start Triggering Event in any outgoing SIP (service) 
signalling message. The P-CSCF should provide an indication to the Management System following the unsuccessful 
authentication of the service level tracing Start Triggering Event. 

When an IMS NE does not have an active trace session when it receives an incoming SIP (service) signalling message 
that contains a service level tracing Start Trigger Event, the IMS NE shall not initiate a Trace Recording Session and 
should forward in an appropriate outgoing SIP (service) signalling message the same service level tracing Start Trigger 
Event. 

4.2.3.5.4 Charging concepts for Service Level Tracing for IMS 

Charging for Service Level Tracing for IMS shall be fulfilled using IMS charging mechanism as specified in 
TS 32.240 [19] and TS 32.260 [20]. 

It shall be possible to apply specific tariffs (e.g. zero rating) to the bearer and/or signalling traffic associated with 
services subjected to Service Level Tracing for IMS. 

As described in subclause 4.2.3.5 an IMS NE that has an active trace session should start a trace recording session when 
it detects a service level tracing Start Triggering Event. An IMS NE shall also provide an indication in the generated 
charging information that service level tracing has been applied. 
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4.2.4 Stopping a trace recording session - management based 

4.2.4.1 UTRAN stopping mechanisms 

Editor's Note: The Trace Recording Session in the RNC shall be stopped when the last connection, which belongs to 
the traced subscriber/mobile, is released. 

4.2.4.2 PS Domain stopping mechanisms 

In SGSN, GGSN and BM-SC a Trace Recording Session shall be stopped when any of the defined stop triggering 
events occur. If Trace Session deactivation is received during the Trace Recording Session, the SGSN is allowed to 
finish tracing of the on-going procedures (e.g. session). In this case the Trace Recording Session shall be stopped 
between the reception of the Trace Session deactivation and the appropriate stop-triggering event. 

The following figure illustrates the successful case in tracing a PDP context when a Trace Recording Session is stopped. 
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The following figure illustrates the successful case in tracing a MBMS context when a Trace Recording Session is 
stopped. 
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4.2.4.3 



CS Domain stopping mechanisms 



In MSC Server a Trace Recording Session shall be stopped when any of the defined stop triggering events occur. If 
Trace Session deactivation is received during the Trace Recording Session, the MSC Server is allowed to finish tracing 
of the on-going procedures (e.g. calls). In this case the Trace Recording Session shall be stopped in MSC Server 
between the reception of the Trace Session deactivation and the appropriate stop-triggering event. 

The following figure illustrates the successful case in tracing a call and the time of stopping a Trace Recording Session. 
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Figure 4.2.4.3.1 : Stopping a Trace Recording Session (IVIanagement Based) - CS domain 

4.2.4.4 IP Multimedia Subsystem stopping mechanisms 

Editor's Note: For further study. 



ETSI 



3GPP TS 32.422 version 7.2.0 Release 7 48 ETSI TS 1 32 422 V7.2.0 (2007-06) 

4.2.5 Stopping a trace recording session - signalling based 

4.2.5.1 UTRAN stopping mechanisms 

In an RNC the Trace Recording Session will always be the same as the Trace Session as no triggering events are 
defined in UTRAN. Therefore a Trace Recording Session shall always be stopped in an RNC when the RNC 
deactivates the Trace Session. For more information on Trace Session deactivation in UTRAN see subclause 4. 1 .4.2. 

4.2.5.2 PS Domain stopping mechanisms 

A Trace Recording Session shall be stopped when the SGSN/GGSN/BM-SC detect any of the stop triggering events. 

However, if a SGSN receives a Trace Session deactivation either from its EM (in case of tracing roaming subscribers) 
or from HSS (in case of tracing home subscribers) during an ongoing Trace Recording Session, it may stop it 
immediately or at any time until the occurrence of an appropriate stop-triggering event. 

A GGSN shall stop a Trace Recording Session when it receives a Trace Session deactivation message (GTP- Update 
PDP Context Request and Trace Activity Control is set to Trace Deactivation )from the SGSN or at any time until the 
occurrence of an appropriate stop-triggering event. 

A BM-SC shall stop a Trace Recording Session when it receives a Diameter Gmb STR message from the GGSN or at 
any time until the occurrence of an appropriate stop-triggering event. 

When a Trace Recording Session is stopped in a SGSN, the SGSN shall send a Trace Session deactivation message to 
the NEs where tracing was required, as defined in the "List of NE types" configuration parameter, received in the Trace 
Session activation message. The Trace Reference, used for the deactivation procedure, shall be the same as used in the 
SGSN for the activation of the Trace Session. 
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The following figure illustrates a successful case in tracing a PDP context, when a Trace Recording Session is stopped. 
(Reference 3GPP TS 23.060 [6].) 
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The following figure illustrates a successfiil case in tracing a MBMS context, when a Trace Recording Session is 
stopped. (Reference 3GPP TS 23.246 [9].) 
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4.2.5.3 CS Domain stopping mechanisms 

A Trace Recording Session shall be stopped when the MSC Server and MGW detect any of the stop triggering events. 

However, if a MSC Server receives a Trace Session deactivation either from its EM (in case of tracing roaming 
subscribers) or from HSS (in case of tracing home subscribers) during an ongoing Trace Recording Session, it may stop 
it immediately or at any time until the occurrence of an appropriate stop-triggering event. 

A MGW shall stop a Trace Recording Session when it receives a MOD command with trace package (indicating Trace 
Deactivation) from the MSC Server or at any time until the occurrence of an appropriate stop-triggering event. 

When a Trace Recording Session is stopped in a MSC Server, the MSC Server shall send a Trace Session deactivation 
message to the NEs where tracing was required, as defined in the "List of NE types" configuration parameter, received 
in the Trace Session activation message. The Trace Reference, used for the deactivation procedure, shall be the same as 
used in the MSC Server for the activation of the Trace Session. 

The following figure illustrates a successful case in tracing a call, when a Trace Recording Session is stopped. 
(Reference 3GPP TS 23.205 [7] and 3GPP TS 23.108 [8].) 
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4.2.5.4 
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The following figure illustrates the stopping of a trace recording session at the UE, P-CSCF, S-CSCF, I-CSCF and HSS 
(Steps 13 to 22) following the unsuccessful attempt of an IP multimedia subsystem procedure. For clarity purposes the 
starting of trace recording sessions are also illustrated (steps 1 to 12). In the case where the HSS is unable to fulfil a 
Diameter User location query from the I-CSCF (see 3GPP TS 29.228 [16]), the HSS shall return to the I-CSCF a 
permanent failure in the Diameter location query response (Steps 13 and 15). At this point the HSS and the I-CSCF 
shall stop their trace recording sessions (Steps 14 and 16). On reception of the SIP Final Response containing the 
permanent failure status code the S-CSCF, P-CSCF and UE stop their trace recording sessions (Steps 17 to 22). 
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4.2.5.5.2 Stopping mechanism at tine UE 

A UE (both originating and terminating) shall stop a trace recording session immediately following: 

1) The termination of an IP multimedia subsystem procedure (as defined in 3GPP TS 23.228 [15]). For 
example, when a successfully established IP multimedia subsystem session ends, or upon a SIP Final 
Response message (2xx, 3xx, 4xx, 5xx and 6xx response codes). 

2) The detection of a stop-triggering event (e.g. time expiry period) as defined by the trace control and 
configuration parameters within the received management operation. 

3) The detection of a stop-triggering event originating directly from the Device Management server for a 
specific Trace Recording Session(s). 

Depending on Operator conditions, when a UE receives from the Device Management server a request to deactivate the 
management operation it shall either: 

1) Continue the Trace Recording Session (s) until it ends gracefully; or 

2) Stop the Trace Recording session (s) immediately. 

In all cases, the UE shall deactivate the Trace Session (s) immediately at the end of the Trace Recording Session(s). 

When a UE receives a request to deactivate the management operation no new Trace Recording sessions shall be 
initiated. 

4.2.5.5.3 Stopping mechanism at the IMS NE 

An IMS NE (i.e. S/I/P-CSCF, AS, HSS, MRF, MGCF, BGCF) shall stop a trace recording session immediately 
following: 

1) The termination of an IP multimedia subsystem procedure (as defined in 3GPP TS 23.228 [15]). For example, 
when a successfully established IP multimedia subsystem session ends. 

2) The detection of a stop-triggering event (e.g. time expiry period) as defined in the Trace Session Activation 
message. 

When an IMS NE receives a Trace Session deactivation during an ongoing Trace Recording Session, it may stop the 
Trace Recording Session immediately or at any time until the occurrence of an appropriate stop-triggering event. 

4.2.6 Service level tracing Trace session deletion and trace retrieval 

As described in clause 4.1.4.6.3, Trace Session deactivation shall be initiated from the Device Management Server. 
Following the completion of any trace recording sessions at the UE and during the subsequent deactivation of the Trace 
Session, the UE shall indicate to the Device Management server that Trace Records are available for retrieval. 

Once the Trace records have been retrieved the management object may be deleted from the UE. 

Editor's note: Detailed description of the processes involved with the removal of the management operation from 
the UE is FES. 
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5 Trace control and configuration parameters 

5.1 Triggering events (IVI) 

This mandatory parameter defines when to start a Trace Recording Session and which message shall be recorded first, when to stop a Trace Recording Session and which 
message shall be recorded last respectively. The messages in the start triggering event tables indicate the transaction to be recorded first and the starting time of the Trace 
Recording Session within a Trace Session for the traced MS/subscriber in the given NE. 

The messages in the stop triggering event tables indicate the transaction to be recorded last and the stopping time of the Trace Recording Session. 
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SGSN 


Start triggering events 


Stop triggering events 


PDP Context 
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Reception of the initial SIP INVITE request 


Sending of the SIP response to the SIP BYE request (sending or receiving) or any other error response 


SIP REGISTER method 


Reception of SIP REGISTER request 


Sending the SIP response to the SIP REGISTER request 


SIP MESSAGE method 


Reception of SIP MESSAGE request 


Sending the SIP response to the SIP MESSAGE request 


SIP SUBSCRIBE 
method 


Reception of SIP SUBSCRIBE request 


Sending the SIP response to the final SIP NOTIFY request 


other SIP methods 


Reception of any other SIP requests 
(e.g. OPTIONS, REFER, INFO) 


Sending the SIP response to the appropriate SIP request 



P-CSCF 


Start triggering events 


Stop triggering events 


SIP INVITE session 


Reception of the initial SIP INVITE request 


Sending of the SIP response to the SIP BYE request (sending or receiving) or any other error response 


SIP REGISTER method 


Reception of SIP REGISTER request 


Sending the SIP response to the SIP REGISTER request 


SIP MESSAGE method 


Reception of SIP MESSAGE request 


Sending the SIP response to the SIP MESSAGE request 


SIP SUBSCRIBE 
method 


Reception of SIP SUBSCRIBE request 


Sending the SIP response to the final SIP NOTIFY request 


other SIP methods 


Reception of any other SIP requests 
(e.g. OPTIONS, REFER, INFO) 


Sending the SIP response to the appropriate SIP request 



BM-SC 


Start triggering events 


Stop triggering events 


MBMS Multicast service 
activation 


Reception of MBMS Authorization 
Request 


Reception of Deactivation Indication for user deactivation or sending of Session Stop Request for 
service deactivation 
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Bits 



Bit 7 



Bit 6 



Bits 



Bit 4 



Bits 



Bit 2 



Bit1 



MSC Server 



MGW 



SGSN 



GGSN 



BM-SG 



spare 



IVISC Server 


Bits 1 Bit 7 


Bit 6 


Bits 


Bit 4 


Bits 


Bit 2 


Bit1 


spare 


spare 


SS 


Handovers 


LU, IMSI attach, IMSI detach 


MO and MT SMS 


MO and MT calls 


spare 



MGW 


Bits 


Bit 7 


Bit 6 1 Bit S 


1 Bit 4 


Bits 


Bit 2 


Bit1 


spare 


spare 


Context 



SGSN 


Bits 


Bit 7 1 Bit 6 


Bits 


Bit 4 


Bits 


Bit 2 


Bit1 


spare 


MBMS Context 


RAU, GPRS attach, GPRS detach 


MO and MT SMS 


PDP context 


Reserved 



GGSN 


Bits 


Bit 7 


Bit 6 1 Bit S 


Bit 4 


1 Bits 


Bit 2 


Bit1 


spare 


MBMS Context 


PDP Context 



BIVI-SC 


Bits 


Bit 7 


Bit 6 


Bits 


Bit 4 


Bit S 1 Bit 2 


Bit1 


spare 


MBMS Multicast service activation 



If a bit is set to 1 the given event shall be traced, i.e. a Trace Recording Session shall be started for that event. 
If a bit is set to the given event should not be traced, i.e. Trace Recording Session should not be started. 

5.1 a Service Level Tracing Start Triggering event (IVI) 

The Service Level Tracing Start Triggering Event is a mandatory parameter that controls and coordinates the start of a 
Trace Recording Session at an IMS NE and UE. 

The Service Level Tracing Start Trigger Event shall include: 
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• Public User Identity (M); 

• Service identification (M); 

• Trace reference (M); 

• Service level tracing counter (M); 

The service level tracing counter is incremented on a hop-by-hop basis to indicate the sequence of trace records 
recorded across all IMS NEs. 



5.2 Trace Depth (M) 



This mandatory parameter defines how detailed information should be recorded in the Network Element. The following 
table describes the values of the Trace Depth parameter. 



Trace Depth 


Meaning 


Minimum 


Recording of some lEs in tlie signalling messages plus any vendor specific extensions to this definition, in 
decoded format. 


IVIedium 


Recording of some lEs in the signalling messages together with the radio measurement IBs plus any 
vendor specific extensions to this definition, in decoded format. 


IVIaximum 


Recording entire signalling messages plus any vendor specific extensions to this definition, in encoded 
format. 



At least one of Minimum, Medium or Maximum trace Depth shall be supported depending on the NE type (see trace 
record description in TS 32.423 [3] for details). 

Trace depth shall be an enumerated parameter with the following possible values: 

- Minimum, 

1 - Medium and 

2 - Maximum 



5.3 List of NE types (M) 



This mandatory parameter defines the Network Element types where Trace Session activation is needed. This parameter 
has meaning only in the signalling based activation mechanism and it is used to determine whether the Trace Session 
Activation shall be propagated further to other Network Elements. In management based activation mechanism this 
parameter is not needed. 

The following list contains the Network Element types: 

MSC Server 

MGW 

RNC 

SGSN 

GGSN 

BM-SC 



Bits 


Bit 7 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Bit1 


spare 


spare 


BM-SC 


RNC 


GGSN 


SGSN 


MGW 


MSC-S 


spare 



If a bit is set to 1, Trace Session to that Network Element shall be activated. 
If a bit is set to 0, Trace Session is not needed in that Network Element. 

5.4 List of interfaces (O) 

This is an optional parameter, which defines the interfaces to be recorded in the Network Element. 
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The following list contains the list of interfaces in each Network Element: 

MSC Server: A, lu-CS, Mc and MAP (G, B, E, F, D, C) interfaces, CAP. 

MGW: Mc, Nb-UP, lu-UP. 

RNC: lu-CS, lu-PS, lur, lub and Uu interfaces. 

SGSN: Gb, lu-PS, Gn, MAP (Gr, Gd, Gf), CAP (Ge) and Gs interfaces. 

GGSN: Gn, Gi and Gmb interfaces. 

S-CSCF: Mw, Mg, Mr and Mi interfaces. 

P-CSCF: Gm and Go interfaces. 

HSS: MAP (C, D, Gc, Gr) and Cx interfaces and location and subscription information. 

BM-SC: Gmb interface. 



Bits 



Bit 7 



Bite 



Bits 



Bit 4 



Bits 



Bit 2 



Bit1 



MSC Server 



MGW 



SGSN 



GGSN 



RNC 



BM-SC 



IVISC Server 


Bits 


Bit 7 


Bite 


Bits 


Bit 4 


Bits 


Bit 2 


Bit1 


CAP 


MAP-F 


MAP-E 


MAP-B 


MAP-G 


Mc 


lu 


A 


spare 


MAP-C 


MAP-D 



SGSN 


Bits 


Bit 7 


Bite 


Bits 


Bit 4 


Bits 


Bit 2 


Bit1 


Ge 


Gs 


MAP-Gf 


MAP-Gd 


MAP-Gr 


Gn 


lu 


Gb 


spare 



IMGW 


Bits 


Bit 7 


Bite 


Bits 


1 Bit 4 


Bits 


Bit 2 


Bit1 


spare 


lu-UP 


Nb-UP 


Mc 



GGSN 


Bits 


Bit 7 


Bite 


Bit S 1 Bit 4 


Bits 


Bit 2 


Bit1 


spare 


Gmb 


Gi 


Gn 



RNC 


Bits 


Bit 7 1 


Bite 


Bits 




Bit 4 


Bits 


Bit 2 


Bit1 


spare 


Uu 


lub 


lur 


lu 



BIVI-SC 


Bits 


Bit 7 


Bite 


Bit S 1 Bit 4 


Bits 


Bit 2 


Bit1 


spare 


Gmb 



If a bit is set to 1, the interface should be traced in the given Network Element. 
If a bit is set to 0, that interface should not be traced in the given Network Element. 
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5.5 Trace Reference (M) 

This parameter shall be a 3 byte Octet String. 

5.6 Trace Recording Session Reference (M) 

This parameter shall be a 2 byte Octet String. 
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Annex A (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Cat 


Old 


New 


Jun 2006 


SA 32 


SP-060261 


0021 


- 


Introduction of Service Level Tracing for IMS 


B 


6.5.0 


7.0.0 


Sep 2006 


SA_33 


SP-060552 


0022 




Add general mechanism for starting trace recording sessions at IMS 
Network Elements and UE - to support end-to-end Service Level Tracing 
for IMS 


B 


7.0.0 


7.1.0 


Sep 2006 


SA 33 


SP-060552 


0023 


- 


Add definition of Service Level Tracing Start Triggering Event 


B 


7.0.0 


7.1.0 


Sep 2006 


SA 33 


SP-060552 


0024 


- 


Clarification of Trace session deactivation mechanism 


F 


7.0.0 


7.1.0 


Sep 2006 


SA_33 


SP-060552 


0025 


- 


Add sending of trace control and configuration parameters for service level 
tracing 


B 


7.0.0 


7.1.0 


Sep 2006 


SA 33 


SP-060552 


0026 


- 


Add starting trace recording at IMS network elements 


B 


7.0.0 


7.1.0 


Sep 2006 


SA 33 


SP-060552 


0027 


- 


Add charging concepts for Service Level Tracing for IMS 


B 


7.0.0 


7.1.0 


Sep 2006 


SA 33 


SP-060552 


0028 


- 


Add stopping trace recording mechanism for service level tracing 


B 


7.0.0 


7.1.0 


Dec 2006 


SA 34 


SP-060727 


0029 


- 


Clarification to the sending of optional trace parameters 


F 


7.1.0 


7.2.0 


Dec 2006 


SA 34 


SP-060727 


0030 


- 


Network initiated re-authentication for SLT 


B 


7.1.0 


7.2.0 


Dec 2006 


SA 34 


SP-060727 


0031 


- 


Trace Session Deactivation at an IMS NE 


B 


7.1.0 


7.2.0 


Dec 2006 


SA 34 


SP-060727 


0032 


- 


Service level trace processes at the UE 


B 


7.1.0 


7.2.0 


Dec 2006 


SA 34 


SP-060727 


0033 


- 


Reception of SLT Start Trigger Event at an IMS NE 


B 


7.1.0 


7.2.0 


Dec 2006 


SA 34 


SP-060727 


0034 


- 


Service level tracing for IMS starting mechanism 


B 


7.1.0 


7.2.0 


Dec 2006 


SA 34 


SP-060727 


0035 


- 


Consistent usage of Service Level Tracing Start Triggering Event 


D 


7.1.0 


7.2.0 


Dec 2006 


SA 34 


SP-060727 


0036 


- 


Retrieval of Trace Records from a UE 


B 


7.1.0 


7.2.0 
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History 



Document history 


V7.2.0 


June 2007 


Publication 
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